1.2 비결정성(Nondeterminism)의 기술적 근원과 이해

1.2 비결정성(Nondeterminism)의 기술적 근원과 이해

1. 인공지능 시대의 새로운 원죄: 비결정성의 정의와 배경

전통적인 소프트웨어 공학, 즉 소프트웨어 1.0의 세계에서 프로그램은 명시적인 명령문의 집합이었다. 개발자가 작성한 코드는 특정한 입력에 대해 언제나 동일한 출력과 상태 변화를 보장하는 결정론적(Deterministic) 시스템을 지향했다. 하지만 딥러닝과 거대 언어 모델(LLM)이 주도하는 소프트웨어 2.0 시대에 접어들며, 우리는 시스템의 핵심 엔진 자체가 본질적으로 확률적이며 비결정적인 특성을 내포하고 있음을 목격한다. 비결정성(Nondeterminism)이란 동일한 입력값과 환경 설정을 제공했음에도 불구하고, 실행 시점이나 조건에 따라 출력값이 달라지는 현상을 의미한다.

이 현상은 단순히 모델이 ’창의적’이기 때문에 발생하는 것이 아니다. 많은 사용자가 temperature=0 설정을 통해 모델을 결정론적으로 만들 수 있다고 믿지만, 실제 연구 결과에 따르면 API를 통해 제공되는 대부분의 LLM은 이러한 설정에서도 출력의 변동성을 보인다. 이러한 비결정성은 소프트웨어의 재현성(Reproducibility)을 저해하고, 품질 보증(QA) 체계를 무너뜨리며, 보안 및 규제 준수 측면에서 심각한 위협이 된다. 따라서 비결정성을 이해하는 것은 AI 기반 소프트웨어 개발의 신뢰성을 확보하기 위한 첫걸음이라 할 수 있다.

2. 부동 소수점 산술의 수치적 한계와 비결합성

비결정성을 유발하는 가장 근본적인 기술적 원천은 하드웨어 수준에서의 수치 연산 방식에 있다. 컴퓨터는 실수를 표현하기 위해 IEEE 754 표준에 기반한 부동 소수점(Floating-Point) 형식을 사용하는데, 이는 무한한 실수를 유한한 비트로 근사하는 과정에서 필연적으로 정밀도의 한계를 가질 수밖에 없다.

2.1 부동 소수점 덧셈의 비결합성(Non-associativity)

수학적 실수의 세계에서는 덧셈의 결합 법칙이 성립하지만, 부동 소수점 산술에서는 그렇지 않다. 즉, a, b, c 세 숫자를 더할 때 연산 순서에 따라 결과가 미세하게 달라질 수 있다.
(a + b) + c \neq a + (b + c)
이러한 현상이 발생하는 이유는 두 부동 소수점 숫자를 더할 때 더 큰 지수(Exponent)를 가진 숫자에 맞춰 작은 숫자의 가수(Mantissa)를 시프트(Shift)하기 때문이다. 이 과정에서 유효 비트 범위를 벗어나는 하위 비트들이 탈락하는 반올림 오차(Rounding Error)가 발생한다. 연산 순서가 바뀌면 이 시프트와 반올림이 일어나는 시점이 달라져, 최종 결과의 최하위 비트(LSB) 수준에서 차이가 생기게 된다. 거대 모델의 추론 과정에서는 수조 번의 행렬 곱셈과 덧셈이 수행되므로, 이러한 미세한 오차는 순방향 전파(Forward Pass) 과정에서 누적되고 증폭되어 최종 출력인 로짓(Logits) 값에 유의미한 변화를 가져온다.

2.2 데이터 정밀도 형식에 따른 영향

모델의 효율성을 위해 사용되는 하위 정밀도 형식들은 이러한 비결정적 오차에 더욱 취약하다. FP32(Single Precision)에서 FP16(Half Precision)이나 BF16(Bfloat16)으로 내려갈수록 가수부의 비트 수가 줄어들어 정밀도 손실과 비결합성으로 인한 변동성이 커진다.

정밀도 형식총 비트가수 비트(Precision)비결정성에 미치는 영향
FP323223수치적 안정성이 높으나 연산 비용이 큼 \vert 상대적으로 낮은 변동성
FP161610정밀도가 낮아 반올림 오차 누적 위험이 큼 \vert 비결정성 증폭의 주요 원인
BF16167수치 범위를 유지하나 정밀도는 낮음 \vert 딥러닝 학습에는 유리하나 추론 시 오차 발생 가능성 존재

이러한 수치적 불안정성은 단순한 수치의 차이를 넘어, Softmax 레이어 직전의 로짓 값 순위를 뒤바꿈으로써 T=0 설정에서도 서로 다른 토큰이 선택되게 만드는 결정적인 도화선이 된다.

3. GPU 병렬 아키텍처와 실행 순서의 가변성

부동 소수점의 수치적 특성이 비결정성의 ’씨앗’이라면, GPU의 대규모 병렬 처리 구조는 그 씨앗을 발아시키는 ’토양’이 된다. LLM의 추론은 수천 개의 코어를 가진 GPU에서 극도의 병렬화를 통해 이루어지는데, 이 과정에서 연산의 순서가 매번 보장되지 않는다.

3.1 스레드 스케줄링과 레이스 컨디션

GPU 내부는 수많은 스트리밍 멀티프로세서(SM)로 구성되어 있으며, 각 SM 내의 스레드들은 하드웨어 스케줄러에 의해 동적으로 할당된다. 운영체제의 부하 상태, GPU 온도에 따른 클럭 조절(Thermal Throttling), 다른 프로세스와의 자원 경합 등 외부 요인에 의해 스레드의 실행 완료 순서는 미세하게 달라질 수 있다.

특히 여러 스레드가 공유 메모리의 동일한 주소에 결과를 더해야 하는 리덕션(Reduction) 연산에서 문제가 두드러진다. 성능 최적화를 위해 사용되는 ‘원자적 덧셈(Atomic Add)’ 연산은 데이터의 무결성은 보장하지만, 각 스레드가 도착하여 값을 더하는 ’순서’는 보장하지 않는다. 앞서 언급한 비결합성 원리에 따라, 스레드 A가 먼저 더해지느냐 스레드 B가 먼저 더해지느냐에 따라 최종 합산 결과는 비트 수준에서 달라지게 된다.

3.2 분산 컴퓨팅과 모델 병렬화

최근의 거대 모델은 단일 GPU에 담기지 않아 여러 개의 GPU에 모델을 쪼개어 올리는 모델 병렬화(Model Parallelism)나 텐서 병렬화(Tensor Parallelism)를 사용한다. 이 경우 GPU 간 데이터를 주고받는 All-Reduce와 같은 통신 연산이 빈번하게 발생한다. 네트워크 지연이나 통신 경로의 가변성은 각 GPU가 데이터를 수신하고 로컬 연산을 수행하는 시점에 차이를 발생시키며, 이는 시스템 전체의 비결정성을 가중시키는 요소가 된다.

4. 딥러닝 프레임워크와 하부 라이브러리의 최적화 전략

우리가 사용하는 PyTorch나 TensorFlow와 같은 고수준 프레임워크와 그 하부에서 동작하는 cuDNN, cuBLAS 라이브러리 또한 성능을 위해 결정론을 포기하는 경우가 많다.

4.1 알고리즘 오토튜닝(Autotuning)의 함정

NVIDIA의 cuDNN 라이브러리는 특정 연산을 수행할 때 최적의 성능을 내는 알고리즘을 찾기 위해 ‘벤치마킹’ 모드를 제공한다. 예를 들어 torch.backends.cudnn.benchmark = True 설정을 사용하면, 프레임워크는 초기 실행 시 여러 합성곱(Convolution) 알고리즘을 테스트하여 가장 빠른 것을 선택한다. 이 과정에서 발생하는 미세한 하드웨어 노이즈로 인해 실행 시마다 서로 다른 알고리즘이 선택될 수 있으며, 알고리즘에 따라 연산 경로와 순서가 다르기 때문에 출력값의 차이가 발생할 수 있다.

4.2 비결정적 커널의 기본값 채택

일부 GPU 연산 커널들은 구조적으로 비결정적인 알고리즘만을 지원하거나, 결정론적 알고리즘이 존재하더라도 성능상의 이유로 비결정적 버전을 기본값으로 사용한다. PyTorch의 scatter_add_, index_add 등은 병렬 성능을 위해 비결정적 리덕션을 사용하도록 설계되어 있다. 비록 최신 프레임워크에서 use_deterministic_algorithms와 같은 플래그를 도입하여 이를 제어하려 노력하고 있으나, 모든 연산을 결정론적으로 수행하려면 상당한 성능 저하(최대 수 배 이상의 속도 저하)를 감수해야만 한다.

5. 전문가 혼합(Mixture-of-Experts, MoE) 아키텍처와 환경적 간섭

GPT-4와 같은 최신 모델들이 채택한 Sparse MoE 아키텍처는 비결정성의 원인을 모델 외부의 ’환경’으로 확장시킨다. MoE 모델은 모든 파라미터를 사용하지 않고, 각 토큰을 처리할 최적의 ‘전문가(Expert)’ 레이어를 동적으로 선택하여 보낸다.

5.1 동적 라우팅과 전문가 용량 제한

각 토큰이 어느 전문가에게 전달될지는 게이팅 네트워크(Gating Network)에 의해 결정된다. 시스템의 효율적 운영을 위해 각 전문가는 한 배치(Batch) 내에서 처리할 수 있는 토큰의 최대 개수인 ’전문가 용량(Expert Capacity)’을 가진다. 만약 특정 전문가에게 토큰이 몰리면, 용량을 초과한 토큰들은 차선위 전문가에게 재할당(Rerouting)되거나 무시된다.

이 재할당 프로세스는 개별 문장의 내용뿐만 아니라, 동일한 배치 내에 포함된 ’다른 문장의 토큰 구성’에 의존한다. 상용 API 환경에서는 여러 사용자의 요청을 실시간으로 묶어 배치로 처리하므로, 내가 보낸 질문이 어떤 다른 질문과 함께 배치에 담기느냐에 따라 내 질문 속 토큰의 연산 경로가 달라질 수 있다. 이는 사용자가 제어할 수 없는 외부의 무작위성이 시스템 내부로 유입되는 통로가 된다.

비결정성 유형주요 원인영향 범위
수치적 비결정성부동 소수점 비결합성, 정밀도 손실 \vert 모든 연산 레이어, 로짓 값 변화
실행 시 비결정성GPU 스레드 스케줄링, 원자적 연산 순서 \vert 동일 하드웨어 내 반복 실행 시 변동성
구조적 비결정성MoE 동적 라우팅, 전문가 용량 제한 \vert 공유 배치 환경에서의 타 요청 간 간섭
알고리즘 비결정성라이브러리 오토튜닝, 비결정적 커널 선택 \vert 프레임워크 및 라이브러리 버전 의존성

6. 추론 서비스 최적화: 배치 불변성(Batch Invariance)의 결여

성능 지향적인 추론 엔진(vLLM, TensorRT-LLM 등)의 최적화 기술 또한 비결정성을 심화시키는 요인이다. ‘연속 배치(Continuous Batching)’ 기술은 새로운 요청이 들어올 때마다 대기 중인 배치에 동적으로 끼워 넣는데, 이는 연산의 물리적 형태와 순서를 매번 변화시킨다.

대부분의 딥러닝 커널은 ’배치 불변성(Batch Invariance)’을 완벽하게 충족하지 못한다. 즉, 입력 시퀀스 S를 단독으로 처리할 때의 결과와, 다른 시퀀스 S', S''와 함께 배치로 처리할 때의 결과가 비트 수준에서 일치하지 않는 경우가 발생한다. RMSNorm이나 Attention 연산 시 배치 크기에 따라 병렬화 전략이 달라지며, 이는 앞서 설명한 비결합성 문제와 맞물려 미세한 결과 차이를 만든다. 최근 연구 논문인 “Defeating Nondeterminism in LLM Inference“에서는 이러한 문제를 해결하기 위해 배치 크기에 관계없이 연산 순서를 고정하는 ’배치 불변 커널’의 필요성을 강조하고 있다.

7. 디코딩 알고리즘의 확률적 샘플링과 로짓의 나비효과

모델의 최종 단계에서 문장을 생성하는 디코딩 과정은 비결정성이 가시화되는 지점이다. LLM은 다음 토큰에 대한 확률 분포를 출력하고, 샘플링 알고리즘(Temperature, Top-p, Top-k 등)이 그중 하나를 선택한다.

7.1 온도(Temperature)와 확률 분포의 변형

온도 파라미터 T는 로짓 값을 Softmax에 통과시키기 전에 스케일링하여 분포의 날카로움을 조절한다. T가 높을수록 확률이 낮았던 토큰들이 선택될 기회가 많아지며, 이는 의도적인 비결정성을 부여하는 방식이다. 반대로 T=0은 확률이 가장 높은 토큰만을 선택하는 탐욕적 디코딩(Greedy Decoding)을 의미하며, 이론적으로는 결정론적이어야 한다.

7.2 로짓 불안정성과 토큰 선택의 역전

문제는 수치적·하드웨어적 원인으로 인해 로짓 값이 아주 미세하게(10^{-6} 이하) 변동할 때 발생한다. 두 토큰 A, B의 확률 차이가 극히 작을 때, 이러한 미세 오차로 인해 A와 B의 순위가 뒤바뀌는 ‘플립(Flip)’ 현상이 나타날 수 있다. LLM은 이전 토큰이 다음 토큰 생성의 입력이 되는 자기회귀(Autoregressive) 구조이므로, 단 하나의 토큰이 바뀌는 것만으로도 이후 생성되는 전체 문맥이 완전히 달라지는 ’나비효과’가 발생한다. 연구에 따르면 이러한 변동성은 토큰 확률이 0.1에서 0.9 사이의 모호한 구간에 있을 때 가장 극심하게 나타난다.

8. 소프트웨어 엔지니어링 2.0: 비결정성의 수용과 새로운 패러다임

안드레 카파시가 명명한 ’소프트웨어 2.0’은 코드를 직접 짜는 것이 아니라 최적화(학습)를 통해 발견하는 시대이다. 이 패라다임에서 비결정성은 단순한 ’오류’라기보다는 시스템이 가진 본질적인 속성에 가깝다.

8.1 결정론적 오라클의 부재와 검증의 난제

전통적인 소프트웨어 테스트에서는 assert output == expected와 같은 명확한 검증이 가능했다. 하지만 비결정적인 AI 출력에 대해서는 이러한 방식이 통하지 않는다. 동일한 요청에 대해 매번 다른 응답이 오는데, 그 응답들이 모두 ’내용상으로는 정답’일 수 있기 때문이다. 이를 ’오라클 문제(Oracle Problem)’라 부르며, AI 출력의 유효성을 판단할 확정적인 기준이 부족함을 의미한다.

또한, 비결정성은 보안 측면에서도 취약점을 만든다. 공격자는 모델의 미세한 출력 변화를 분석하여 모델이 실행되는 하드웨어 구성, 배치 사이즈, 혹은 서버 부하 상태와 같은 내부 정보를 유추(Side-channel Attack)할 수 있다. 이는 AI 시스템이 단순히 논리적 결함뿐만 아니라 확률적 변동성으로 인해 보안 위협에 노출될 수 있음을 시사한다.

9. 비결정성의 정량적 측정과 지표

비결정성을 엔지니어링적으로 관리하기 위해서는 이를 수치화할 수 있어야 한다. 최근 연구에서는 다음과 같은 지표들이 사용되고 있다.

  1. Total Agreement Rate (TAR): 동일한 입력에 대해 N번 실행했을 때, 출력값이 완전히 일치하는 비율을 측정한다. 원문 텍스트의 일치도를 보는 TAR_r과 파싱된 정답의 일치도를 보는 TAR_a로 나뉜다.
  2. Shannon Entropy: 출력되는 토큰들의 확률 분포의 무질서도를 측정하여, 모델이 특정 시점에서 얼마나 불확실한 결정을 내리고 있는지를 정량화한다.
  3. Accuracy Variation: 동일한 벤치마크 테스트를 반복 수행할 때 나타나는 정확도의 편차를 측정한다. 연구에 따르면 모델에 따라 실행 간 최대 15% 이상의 정확도 차이가 발생하기도 한다.

이러한 지표들은 우리가 구축한 AI 시스템이 얼마나 ’안정적인지’를 판단하는 척도가 되며, 후속 장에서 다룰 ’오라클’의 성능을 평가하는 기준이 된다.

10. 요약 및 기술적 통찰

비결정성은 하드웨어의 부동 소수점 처리 방식, GPU의 병렬 아키텍처, 딥러닝 프레임워크의 최적화 커널, 그리고 현대적인 MoE 구조와 추론 서버의 배치 전략이 복합적으로 얽혀 발생하는 기술적 산물이다. 이는 temperature=0이라는 단순한 파라미터 설정만으로는 완전히 해결할 수 없는 깊은 기술적 뿌리를 가지고 있다.

AI 기반 소프트웨어 개발자는 이러한 비결정성을 ’제거’해야 할 대상으로만 보지 말고, 시스템의 본질적인 특성으로 이해해야 한다. 성능과 결정론 사이의 트레이드오프를 인식하고, 시스템의 각 계층(하드웨어, 라이브러리, 모델, 디코더)에서 발생하는 변동 요인을 제어하려는 노력이 필요하다. 또한, 이러한 기술적 근원을 이해하는 것은 이후 장에서 상세히 다룰 ’결정론적 오라클’을 왜 설계해야 하는지에 대한 강력한 논리적 근거가 된다. 비결정적인 엔진 위에 신뢰할 수 있는 소프트웨어를 구축하기 위해서는, 그 변동성을 감싸 안고 검증할 수 있는 확정적인 논리 계층이 반드시 동반되어야 하기 때문이다.

11. 참고 자료

  1. Overparameterization: A Connection Between Software 1.0 and, https://dspace.mit.edu/bitstream/handle/1721.1/130046/LIPIcs-SNAPL-2019-1.pdf?sequence=2&isAllowed=y
  2. Software 2.0 – A Paradigm Shift - Robosoft Technologies, https://www.robosoftin.com/blog/software-2-0-a-paradigm-shift
  3. Software 2.0: An Emerging Era of Automatic Code Generation, https://blog.softtek.com/software-2.0-an-emerging-era-of-automatic-code-generation
  4. Non Determinism & Prompt Optimization in LLMs for AI Apps, https://futureagi.com/blogs/non-deterministic-llm-prompts-2025
  5. Reflections on the Reproducibility of Commercial LLM Performance, https://arxiv.org/html/2510.25506v3
  6. Document Analysis with LLMs: Assessing Performance, Bias, and, https://www.scitepress.org/Papers/2025/130943/130943.pdf
  7. Why Temperature=0 Doesn’t Guarantee Determinism in LLMs …, https://mbrenndoerfer.com/writing/why-llms-are-not-deterministic
  8. Non-Determinism of “Deterministic” LLM System Settings in Hosted, https://aclanthology.org/2025.eval4nlp-1.12.pdf
  9. Non-Determinism of “Deterministic” LLM Settings - arXiv.org, https://arxiv.org/html/2408.04667v5
  10. Solving the non-deterministic problem of LLM inference - 36氪, https://eu.36kr.com/en/p/3461963944908162
  11. Token Probabilities Expose Large Language Model Nondeterminism, https://www.researchgate.net/publication/399707525_Beyond_Reproducibility_Token_Probabilities_Expose_Large_Language_Model_Nondeterminism
  12. Defeating Nondeterminism in LLM Inference, The Future is Predictable, https://hackernoon.com/re-defeating-nondeterminism-in-llm-inference-the-future-is-predictable
  13. Incidental Non-Determinism: When AI Surprises You (and Why), https://qwerky.ai/blog/incidental-non-determinism
  14. Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
  15. Impacts of floating-point non-associativity on reproducibility for HPC, https://arxiv.org/html/2408.05148v3
  16. Achieving Consistency and Reproducibility in Large Language …, https://pub.aimind.so/creating-deterministic-consistent-and-reproducible-text-in-llms-e589ba230d44
  17. Deterministic Atomic Buffering, https://www.microarch.org/micro53/papers/738300a981.pdf
  18. Impacts of floating-point non-associativity on reproducibility for HPC, https://www.researchgate.net/publication/387848485_Impacts_of_floating-point_non-associativity_on_reproducibility_for_HPC_and_deep_learning_applications
  19. Beyond Barrier Synchronization in the Verification of GPU Kernels, https://www.doc.ic.ac.uk/~afd/papers/2014/NFM.pdf
  20. Reproducibility of atomic operations - NVIDIA Developer Forums, https://forums.developer.nvidia.com/t/reproducibility-of-atomic-operations/136299
  21. No, this is not true for GPUs. https://www.twosigma.com/articles/a, https://news.ycombinator.com/item?id=37007811
  22. CuDNN Developer Guide | PDF | Thread (Computing) - Scribd, https://www.scribd.com/document/371700731/CuDNN-Developer-Guide
  23. 1 Introduction - arXiv.org, https://arxiv.org/html/2511.17826
  24. torch.use_deterministic_algorithms — PyTorch 2.10 documentation, https://docs.pytorch.org/docs/stable/generated/torch.use_deterministic_algorithms.html
  25. Reproducibility — PyTorch 2.10 documentation, https://docs.pytorch.org/docs/stable/notes/randomness.html
  26. ML Tidbits: Nondeterminism on the GPU | by Tom B Brown - Medium, https://medium.com/tom-b-brown/tensorflow-nondeterminism-on-the-gpu-a0e86125fd06
  27. torch.use_deterministic_algorithms — PyTorch master documentation, https://alband.github.io/doc_view/generated/torch.use_deterministic_algorithms.html
  28. Defeating nondeterminism in LLM inference, in practice - Medium, https://medium.com/@siddhantg314/defeating-nondeterminism-in-llm-inference-in-practice-38a7dd1e4112
  29. Software 2.0 - Andrej Karpathy – Medium, https://karpathy.medium.com/software-2-0-a64152b37c35
  30. Andrej Karpathy: Software Is Changing (Again) - The Singju Post, https://singjupost.com/andrej-karpathy-software-is-changing-again/
  31. Security of Software 1.0 vs 2.0 - Xander Dunn, https://xander.ai/security-of-software-1-0-vs-2-0